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Intellectual Property Rights 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 



Introduction 



IETF IP multicast protocols, in particular their signalling characteristics, are often not well suited to the specifics of 
BSMs, as discussed in TR 102 156. The present document defines the functional architecture that is going to be used to 
specify how and where IP multicast protocols need to be "adapted" to be better suited to the BSM environment. This 
architecture relies heavily on the generic BSM Architecture Technical Specification TS 102 292; it does not use satellite 
specifics, is based on client server architectures and does not interfere with standard IP protocols and Internet 
operations. It applies the BSM architecture to a specific application, multicast. Hence it provides both a test case for the 
architecture and a framework for the TSs that will specify the protocols ensuring multicast services can be provided 
efficiently over BSM networks. 
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Scope 



The present document presents a functional multicast services architecture bringing together the previous BSM TRs on 
Standardisation (see TR 101 984 and TR 101 985) and Multicasting (see TR 102 156) and the TS on BSM Functional 
Architecture (see TS 102 292). It also links in a common framework the current Work Items on Multicast Protocols 
over the BSM. Finally, it provides a functional structure to the subsequent Multicast Technical Specifications (TSs) to 
be produced by the SES Technical Committee. The focus of the present document is on the IP version 4 (IPv4) 
protocols; this is consistent with the other protocol work performed in the BSM working group. 



Void 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

adaptation: process of adapting standard protocols for better performance over a satellite (or other) subnetwork 

architecture: abstract representation of a communications system 

BSM multicast session: instance of a multicast session that originates and terminates within BSM elements (STs, 
gateways) 

function: any discrete element that forms a defined part of an architecture 

multicast group: multicast IP address to which hosts may subscribe 

multicast session: specific instance of multicast communication 

proxy: function that intervenes between a source and destination and performs that function as an intermediary for the 
remote devices in each direction 

scenario: predicted sequence of events 

snooping: function associated with a layer 2 switch or bridge that intervenes on a given layer 3 protocol between a 
source and destination 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3GPP Third Generation Partnership Project 

BSM Broadband Satellite Multimedia 

CBT Core Based Trees 

CSF Client Server Function 

DHCP Dynamic Host Configuration Protocol 

DRM Digital Rights Management 

IETF Internet Engineering Task Force 

IGMP Internet Group Management Protocol 

INT Internet Notification Table 

IP Internet Protocol 

IPv4/v6 Internet Protocol version 4/6 

LAN Local Area Network 

MLD Multicast Listener Discovery 
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MMT Multicast Mapping Table (DVB-RCS) 

PID Packet IDentifier 

PIM-SM Protocol Independent Multicast - Sparse Mode 

QoS Quality of Service 

RFC Request For Comments 

SD Satellite Dependent 

SDAF Satellite Dependent Adaptation Functions 

SI Satellite Independent 

SIAF Satellite Independent Adaptation Function 

SI-C-SAP Satellite Independent - Control plane - Service Access Point 

SI-M-SAP Satellite Independent - Management plane - Service Access Point 

SI-SAP Satellite Independent - Service Access Point 

SI-U-SAP Satellite Independent - User plane - Service Access Point 

SLC Satellite Link Control 

SMAC Satellite Medium Access Control 

SPHY Satellite PHYsical 

SSM Source Specific Multicast 

ST Satellite Terminal 

USB Universal Serial Bus 

WG Working Group 



BSM multicast framework 



The protocols that enable multicast over BSM are located in the satellite independent part of the BSM stack. The 
mapping of these functions to layer 2 protocols, while essential for the operation of the BSM in multicast mode are 
beyond the scope of this architecture but will be addressed under other Work Items of the BSM working group. This 
architecture resides within the Communication Services, which contains all the servers that will enable communication 
to and from the BSM and the Internet and where the BSM protocols are adapted to the outside world (see figure 1). 



4.1 Basic concepts 



In addition to the definitions provided in clause 3.1 and the basic concepts introduced in the Architecture TS 102 292 
some concepts that are necessary to fully understand the BSM multicast services are further explained below: 

• Adaptation: refers to the process of adapting standard protocols for better performance over, in the present 
document, a BSM satellite subnetwork. Adaptation, which should be transparent to the general Internet, 
involves, for example, changing timers, filtering traffic and reducing the transmission of messages over the 
satellite link to the protocol servers. 

• Multicast proxying: refers to operations that are performed on behalf of other devices in order to improve 
performance or cost, for example. An IP layer proxy is a function that intervenes between a source and 
destination of IP packets that relate to a given IP protocol. For multicast group management an IGMP Proxy 
behaves as a single IGMP client on behalf of several downstream hosts, and in the opposite sense as a local 
IGMP querier to these hosts on behalf of a remote querier. 

• multicast session: specific instance of multicast communication by a multicast group defined by its 
transmission parameters, participants, and time of existence. In this context: 

Applications associate a specific source address with a multicast session; the same destination address 
but with a different set of source will be viewed as a different group. 

A group address may need to be interpreted by its scope in the sense that the same address could be used 
in different part of the network independently an issue with BSM networks that cover access domains 
and multiple multicast offerings. 

• snooping: function associated with a layer 2 switch or bridge that intervenes on a given layer 3 protocol 
between a source and destination. It learns about network behaviour from intercepted IP packets and without 
explicit configuration as a network function (with IP address, etc.). 
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4.2 Link to the generic BSIVI architecture 

In the Architecture TS 102 292 the following interfaces are defined in figure 1: 

• CSF-1: The interface between the IETF protocols and the Client function (internal to the IP layer). 

• CSF-2: The interface between the peer IETF Client [interworking] functions. 

• CSF-3: The interface between the Client function and the Server function(s). 

The multicast group management protocol is directly linked to the CSF-3 across the BSM even when using snooping or 
proxying because the protocol architecture is mostly at layer 3. Layer 2 operations related to reverse address resolution 
and packet replication or higher layer network management function are only described here as they relate to 
architectural scenarios. 




Communications 
Services Segment 



Figure 1 : BSM architecture 

In terms of multicasting the BSM architecture can be used to define main functions such as: 

• multicast routing and group management; 

• address resolution/translation; and 

• security. 

These run over the CSF-3 interface and are located mainly above the SI-SAP. The generic BSM multicast architecture 
is shown in figure 2. 
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Protocol 
Adaptation 



Figure 2: BSM generic multicast architecture 

In clause 4, the multicast architectures that are going to be the basis of the proposed TSs are introduced. For each of the 
recommended protocol, a TS specifying the manager or the "adaptation" of the protocol and located in the appropriate 
server (in the appropriate domain) will be defined in relation with the BSM. Both BSM specific modules and IETF 
standard modules are illustrated for completeness. 

4.2.1 Multicast over different BSM topologies 

Multicast protocols over the BSM may operate differently over the different BSM families. The use of double hops for 
transmitting multicast information should be avoided where possible, for example by adding adaptation of protocols 
over meshed networks, but may be un-avoidable in some cases. 

The main difference between the mesh network and star network topologies is with packet forwarding and replication: 
in a star network the hub becomes de facto the virtual source of all multicast traffic. In this configuration all external 
sources appear as sources at the hub and all clients first forward their packet to the hub for redistribution. In a mesh 
topology any ST can be the multicast source. Hence at the BSM level, two instances of multicast can happen: 

• single source or origination multicast (via a gateway at the hub) - this is for star network topology where all 
BSM multicast sessions originate at the gateway (or a single ST); the actual "source" can be anywhere; and 

• multiple source or origination: any ST can be the root node of the BSM multicast session given it is connected 
to the IP multicast source or rendezvous point; any such ST that can transmit data to a particular multicast 
session; a destination ST is a leaf node of the multicast session and is an ST that receives data from a particular 
multicast session; this will necessitate double hops on the data path (via the hub) in all BSMs that do not have 
onboard processing. 
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4.3 BSM multicast-specific protocol stack 

Figure 3 presents the BSM protocol stack specific to multicast; it is taken directly from the BSM functional architecture 
(see TS 102 292). Figure 3 shows how the basic set of functions and SI-SAP primitives for unicast Internet connectivity 
is complemented by multicast specific functions. They correspond to the recommendation of the multicast TR 102 156 
for future work in BSM multicast, namely in the Satellite Independent layers: 

• BSM Multicast Group Management; 

• BSM routing; 

• BSM Multicast Address Resolution; and 

• Multicast Security. 

Because of the nature of the BSM, some of these functions, most notably for routing and group management, will 
necessitate adaptation for better performance with BSM delays and transmission/reception characteristics. Multicast, 
like unicast functions such as DHCP or web access, uses local proxies in the requesting hosts to reduce the control 
traffic load. In the BSM this reduction of traffic is important over the air interface and proxies will be used in addition 
to protocol adaptation. Proxies, essentially virtual devices, are not illustrated in figure 3, which shows protocols only. 
Adaptation and proxying use are defined and specified in clause 5.1. Figure 3 finally indicates some satellite dependent 
group management that is being performed in the BSM WG (SD multicast functions). This work defines how multicast 
groups can be mapped onto Satellite Dependant, for example DVB specifics using the DVB-RCS Multicast Mapping 
Tables (MMT) or DVB Internet Notification Tables (INT). Annex A gives a short overview of the lower layer mapping 
necessary to enable multicast over BSM networks. 
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4.4 Multicast services over the BSIVI 

Multicast operations over the BSM can have muhiple forms: 

• Muhicast session attributes: 

on-demand: when a subnetwork wants to receive muhicast data protocols allow to request the service 
over the BSM (pull model); and 

scheduled: multicast data is sent to all registered users according to a schedule (push model). 

• IP multicast group management attributes: 

static: the ST statically forwards all received groups or a pre-configured set of groups; and 
dynamic: the ST allows attached hosts to dynamically set which groups to forward. 

• Multicast address resolution: 

static: all multicast addresses are preconfigured and only refreshed unfrequently via tables or direct 
operator's intervention; and 

dynamic: multicast addresses are mapped dynamically using an address resolution protocol. 

Since scheduled and static operations do not necessitate any IP layer protocol operations beyond the usual connectivity, 
this architecture is focused on the dynamic multicast management at the IP layer where hosts join and leave multicast 
sessions "at any time". The essential aspects of the architecture cover: 

1) IP Multicast group management via the Internet Group Management Protocol (IGMP) proxying or snooping 
and protocol adaptation that support dynamic join and leave operations this is based on IGMPv2 protocol that 
was successfully adapted to satellite operations. 

2) IP Multicast routing protocols such as the PIM-SM and CBT that are recommended in the ETSI Multicast 
TR 102 156 as well as recent SSM work standardized by RFC 3569. 

3) Multicast address resolution to resolve a IP multicast address to a BSM multicast address. 

4) Multicast Security to define how security policies can be applied to multicast transmissions (e.g. only 
authorized users can receive the content and that the content is protected by the some form of Digital Rights 
Management or DRM). 

IP multicast protocols and their signalling characteristics were originally developed on terrestrial wired LAN or WAN 
technologies. 

EXAMPLE: On wired networks, hosts can listen to the multicast transmission from other hosts and will not re- 
transmit information that was already sent by another host; the amount of traffic to manage group 
membership can thus be reduced. 

Alternatively these protocols can operate over high bandwidth networks where signalling overhead or information 
tunnelling is not an issue. Finally most protocols are tuned to the short delays of the terrestrial networks. None of these 
characteristics belong to the BSM: 

• STs may not be aware of other STs; 

• satellite uplink bandwidth is scarce and delays of the order of seconds common. 

Hence for the BSM, intercepting IGMP, PIM-SM and other IP multicast control traffic at the ST is recommended to 
"adapt" the protocols to the BSM environment. In general the adaptation uses a client server architecture. Proxies will 
also be used when applicable. 
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Multicast protocols over the BSM 



5.1 Adaptation 



While the SI-SAP provides a layer of abstraction that separates layer 3 protocols from the lower layer functions, the 
BSM has specific characteristics as compared with a standard Ethernet such as: 

• long(er) transmission delay; 

• scarce spectrum resources especially on uplink; 

• transmission channels may not be broadcast channels; hence all transmissions may not be heard by all 
terminals, especially uplink transmissions. 

This requires that standard protocols for routing, group management or address resolution to be "adapted" for better 
performance. This adaptation, transparent to the general Internet, involves changing timers, filter and reduce traffic over 
the air messages to the multicast servers. An implementation of such adaptation is provided in TS 102 293 for the group 
management case. 



5.2 Proxying 



In the wired Internet, even with ample bandwidth in the core, the edge networks experience congestion and it is to the 
benefit of operators and users alike to keep the bandwidth for revenue generating traffic. Proxying is used to keep some 
function usually associated with a remote server local to the user by caching frequently requested information and 
acting as the server for a number of usual operations. The cache of information is refreshed periodically with fewer 
commands especially during periods of lower load. Proxying is currently used in the Internet for example for address 
resolution (DHCP proxies), web access (Web proxies) and multicast group management (IGMP proxies). Proxying 
provides the added feature of security (preventing access from an external device to the proxy) and address filtering 
(preventing access to some web sites for example). 

It can be seen when comparing with clause 5.1, that adaptation and proxying are different types of functions: 

• A proxy is not changing anything in the protocol (it is not adapting). A proxy is an agent (a virtual device) and 
has an address and will be directly involved in the communication; for example it is a well-known function of 
any network setup to specify the proxy addresses. 

• The adaptation is not an agent (there is no virtual device). The adaptation function does not have an address: 
you cannot communicate with the adaptation; only with the server running the adapted protocol. 

Layer 3-based multicast STs interfacing with downstream subnetworks can be implemented as either routers or proxies. 
The router version is applicable when multicast routing protocols (e.g. PIM-SM) are carried over the satellite. The 
proxy version is applicable when IGMP is carried over the satellite. 

5.3 IGMP over BSM 

IP Multicast Group management in the sense of management of a multicast tree determines whether a group is 
forwarded and where packet replication happens. Figures 4 and 5 show the operation of IGMP over the BSM with both 
layer 2 (snooping) and layer 3 (proxying) approaches. In both cases IGMP messages are intercepted before they enter 
the BSM. When a host requests to join or leave a multicast group via IGMP, the corresponding ST (the one the host is 
attached to) receives the IGMP message and if necessary makes a request to the querier. After processing of the request 
the receiving ST may start to receive or stop receiving multicast content. Both snooping and proxying are helpful in 
reducing traffic over the BSM. IGMP snooping, as implied by the name, is a feature that allows the ST to "listen in" on 
the IGMP conversation between hosts and routers and can tell the BSM network which groups need not be forwarded, 
hence the traffic reduction at the sender side. Details of the IGMP adaptation are available in TS 102 293. 
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As seen in the clause 5.2, the generic definition of a proxy is an entity performing a function for another device. Like 
many other IP functions, IGMP is often handled through proxy servers when a single interface from several hosts on a 
local subnetwork to the external network to is needed. The IGMP proxy offers a mechanism for multicast forwarding 
based on IGMP membership information. The proxy has to decide about forwarding packets on each of its interfaces 
based on the IGMP information and as such replaces the usual IGMP querier the proxy can be used together with IGMP 
adaptation to reduce traffic over the satellite link or to send traffic only outside peak hours. The proxy gets the multicast 
management messaging (join, leave, prune) and responds to the query locally without necessitating access to the remote 
server. When necessary the proxy will upgrade its information by querying the server but that could be only 
infrequently especially over semi-dynamic or static multicast architecture. While the adapted protocol and the proxy are 
independent and the use of one does not necessitate the other, when used together the performance of the combination is 
improved as it adds the fast response to the user offered by local functions, to the reduced traffic over the air interface 
required by the BSM and adds flexibility of the timing of those transmissions. Such IGMP proxies are commonly used 
and require no modification if they are used at the client side of the satellite (draft-ietf-magma-igmp-proxy-04 - see 
bibliography). 
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5.4 BSM multicast routing 



While IGMP is not strictly a routing protocol, it controls the packet forwarding behaviour by managing who is a member of a multicast group. Once the distribution tree and 
actual routing information has been established in the tables and once packets have been replicated (or not replicated) the forwarding of packets will use a similar mechanism as 
for unicast routing: the multicast routing table will provide the forwarding address to BSM port mapping and the packet will be sent to the actual port. This clause describes how 
multicast routing protocols could be used over a BSM network. 

5.4.1 Sparse-mo(de protocols over BSIVI 

Figure 6 presents an overview of the PIM-SM over BSM adaptation as an example of a sparse mode protocol over the BSM (Core Base Trees or CBT would be other examples). 
PIM-SM is illustrated because it an accepted IETF protocol. Details of this adaptation will be provided in the appropriate TS when it becomes available. A feature of the routing 
adaptation is the need to reduce double hops through the BSM when it can be avoided especially over meshed networks. 
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5.4.2 Other multicast routing protocol adaptation 

As other multicast routing protocols are used over the BSM other adaptation will become available. 

5.5 Multicast address resolution 

Multicast address resolution has both similar and non-similar characteristics when compared to unicast address 
resolution. If a router gets a multicast IP address that is not recognized it sends it to the appropriate BSM server that 
knows about the appropriate multicast tree topology, IP multicast addresses and the mapping to and from the BSM 
multicast addresses. This process also relates to the group management described in previous clauses. 

5.6 Service discovery 

Finding the address of the content to listen to is a multiple level protocol in the BSM that could be automated in some 
cases: 

1) From the content find the IP address; this is done manually via a web page, media guides, etc.; this is the 
service discovery part. 

2) From the multicast IP address find the specific satellite independent BSM multicast address of the channel to 
listen to (address resolution). 

3) From the BSM multicast address find the physical channel to tune to. This involves BSM lower layer functions 
as well as in some case the actual IP multicast addresses (see annex A). 



Scenario 



This clause describes the sequence of events that enable multicast over the BSM. 

• The end user finds a URL or the IP address to the content that is to be received. 

• A join message is sent to the group manager indicating that the host to which this user is connected wishes to 
receive the content. 

• The local proxy verifies if this group is available and if the user (and/or host) is entitled to receive the content. 

If the group is available and the user (and/or host) is authorized the host address is added to the list of 
destinations. The connection handling features of the SI-SAP ensure the multicast address is connected to 
the appropriate lower layer resources. 

If the group is not there, the proxy can request it dynamically to the group manager across the air 
interface or wait for a refresh of available groups. Then the host can be added to the distribution if the 
security allows it. 

If the user is not authorized or the group is unavailable the process stops. 

• The host is added to the multicast tree; periodically this tree is rebuilt to balance traffic and perform 
maintenance; the adaptation in the ST ensures that the required signalling traffic is handled efficiently. 

• Multicast traffic flows from the source to the requesting hosts. 

• When the user disconnects, leave messages are sent and handled by the proxy and/or server. Pruning of the 
tree may occur if the user was alone on a branch. 
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Annex A (informative): 

SI-SAP multicast mapping for DVB networks 

The mapping of specific multicast protocol to Satellite Dependent protocols is described in figure A.l. Figure A.l 
highlights the fact that the DVB semantics are not know above the SI-SAP but the DVB specific information to setup 
actual access to the multicast content is cached at the SDAF layer and indexed by the appropriate BSM identifier. From 
the SIAF to the lower layers the overall mapping involves multiple steps. For example, the mapping of IP multicast 
groups, addresses and QoS requirements to specific channels in the satellite transmission involves steps above and 
below the SI-SAP. The mapping of a certain multicast content addresses to a DVB Packet IDentifier (PID) in the DVB 
TS stream is currently done for example by the DVB RCS MMT tables or DVB INT tables. Since the DVB model does 
not include an abstraction layer for the BSM this mapping will involve the use of SI-SAP semantics to keep the satellite 
dependant information hidden at the higher layers. 
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Figure A.1 : DVB SI-SAP mapping for multicast 



£75/ 



18 



ETSI TS 102 294 V1.1.1 (2004-02) 



Annex B (informative): 
BSIVI multicast options 

Table B.l summarizes the BSM multicast options. 



Table B.l : BSM multicast options 





A 

Number of 

sources 


B 
Control architecture 


C 
Topology 


D 

Signalling 

traffic 


E 
User traffic 


F 
Comments 


1 


Single 
(e.g. via 
Gateway) 


Single central control, 
connected to the 
source 


Star/ 
no-OBP 


Single hop 


Single hop 


No support for sources 
other than Gateway. 


2 


Multiple 
(Gateway and 
Sis) 


Single central control, 
connected to the 
Gateway 


Star/ 
no-OBP 


Single hop 


Double hop 
(ST-Hub-ST) 


Source data from 
remote sources must 
be tunnelled via the 
ST to Gateway as first 
hop. 


3 


Multiple 


Single central control, 
not all connected to the 
Gateway 


Star/no-OBP 


Double hop 


Double hop 


Same as above; STs 
can suppress traffic 
that is not required. 


4 


Multiple 


Multiple; one per 
source, co-located with 
source 


Mesh/OBP 


Single hop 


Single hop 


Multiple control 
messages required 
(one per source). 


5 


Multiple 


Single central control 


Mesh/OBP 


Single hop 


Single hop 


Most control 
messages need a 
single hop. 
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